|
|
|
|
|
|
|
Designing Control Interaction per Form |
|
|
|
|
|
|
|
|
The controller objects for each form are as follows: |
|
|
|
|
|
|
|
|
DepositFunds
OpenAccount
WithdrawFunds
CloseAccount
CancelTransaction
CheckAccountStatus
MDIController
TransactionProcessor
MaintainBankProducts
MaintainCustomer
MaintainAccount
MaintainUsers
MaintainWorkgroups |
|
|
|
|
|
|
|
|
As of this point, the TransactionProcessor controller has responsibility for more than one form. Those forms include |
|
|
|
|
|
|
|
|
frmCashDepositRecord
frmAccountDetail |
|
|
|
|
|
|
|
|
Because the number of forms and controller classes is increasing, you should create two new packages in the Visual Modeler model. To create packages, find the User Services package in the package browser in Visual Modeler. Right-click on the package's corresponding folder and choose New Package from the popup menu. Name one package Forms and the other Controllers. |
|
|
|
|
|
|
|
|
Figure 12.1 shows the forms that are in the Samsona Bank Teller System. Figure 12.2 shows the controllers for the forms. To keep the example as simple as possible, ignore the forms that have very similar functionality, such as frmDeposit and frmWithdraw. You could use one form for these processes, but that requires additional logic for differentiating the type of transaction (which can be determined by the TransactionType property of the respective business classes). |
|
|
|
|
|